I kind of piggybacked on the existing test that covers this functionality, but not sure whether it's a bit dirty!
Please let me know if you'd prefer me to do it in some other way, e.g. create a new fixture specifically for this case. Or perhaps this should be tested in some different place rather than test_main?

Hi @karlicoss,

I think it is perfectly fine to reuse an existing test like this one, thanks!

However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.

But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.

I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

Just thinking aloud here.

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

No, agree, it makes a lot of sense! From experience, such random breakages are pretty annoying. Happy to implement a feature flag and add documentation for it.

I've been thinking about the flag name & documentation.. and actually, perhaps it makes sense to simply reuse consider_namespace_packages?

From my experience with it, right now only helps with package/module names. E.g. if there is a test inside test_pkg.py

src/
    pkg/
        test_pkg.py

And we run PYTHONPATH=src pytest --pyargs pkg.test_pkg

It correctly discovers tests in both cases, but.

• with consider_namespace_packages, it has __package == "pkg" and __module__ == "pkg.test_pkg" (as one might expect)

• without consider_namespace_packages, it has __package == "" and __module__ == "test_pkg"

  If we add pkg/__init__.py, this has correct __package__ and __module__ though.

This is consistent with --help:

Consider namespace packages when resolving module names during import

However, according to https://docs.pytest.org/en/stable/reference/reference.html#confval-consider_namespace_packages

Controls if pytest should attempt to identify namespace packages when collecting Python modules. Default is False.
Set to True if the package you are testing is part of a namespace package.

So the docs say it "should attempt to idenfity when collecting", but I'm not sure what this actually means here.

E.g. if you have the following hierarchy:

src/
    pkg/
        __init__.py
        subpkg/
            test_subpkg.py

pkg is a regular package with __init__.py, but pkg.subpkg is a namespace subpackage.
Then if you run PYTHONPATH=src pytest --pyargs pkg (with upstream pytest), pytest correctly discovers the test in test_subpkg.py

The only difference is

• with consider_namespace_packages it correctly sets __package__ and __module__ in test_subpkg.py
• without, it sets __package__ = ""

From a lurk in pytest code, to me it feels that indeed it has to do more with naming than test discovery -- e.g. I think stuff in this file is mostly after we already collected candidate files to run?

So perhaps if I just reuse consider_namespace_packages, this makes it closer to the original intent? So it could both discover tests under namespace packages (this PR), and they also will have correct __package__/__module__ attributes (already working in upstream pytest).

This also limits the potential impact from the change -- there are "only" 400ish matches for this setting on github https://github.com/search?q=consider_namespace_packages&type=code (tiny amount comparing to total pytest users), and I'd imagine people who use this setting know what they are doing anyway.

What do you think?

Hi @karlicoss,

I think it is perfectly fine to reuse an existing test like this one, thanks!

However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.

But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.

I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

Just thinking aloud here.

Can we add a section to the docs related to this support somewhere in the docs?

Perhaps instead of just returning it blindly, we should check if this is a directory before returning?